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ABSTRACT 


An ad hoc network is a dynamic wireless network with the engagement of cooperative nodes without a fixed infrastructure. Multicasting is intended for 
group communication that supports the dissemination of information from a sender to all the receivers in a group. On the basis of comparison of 
multicasting protocols, Protocol for Unified Multicasting through Announcement (PUMA) has been chosen for initial implementation. PUMA does not rely 
on any unicast routing approach. It delivers data at a higher efficiency, while also providing a tight bound for control overhead in a wide range of network 
scenarios. Secure communication is a major concern in PUMA, especially because multicasting protocols are applied in areas such as audio/ video 
conferencing, corporate communications, collaborative and groupware applications. PUMA achieves desired packet delivery ratio with variable number of 
nodes. The intention of this paper is to bring efficient and secure multicasting with PUMA protocol over the IEEE 802.11 standard. Simulations are carried 
out in the Network Simulator NS-2 to evaluate the performance of the protocol. The results show that PUMA outperforms other multicast protocols in 
terms of throughput, packet delivery ratio and scalability. 
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1. INTRODUCTION 


An ad hoc mobile network (Akshay et al. 2012) is a collection of mobile nodes that are dynamically and arbitrarily located in 
such a manner that the interconnections between nodes are capable of changing on a continual basis. Mobile ad-hoc 
networks operate in the absence of fixed infrastructure. They offer quick and easy network deployment in situations where it is 
not possible otherwise. Nodes in mobile ad-hoc network are free to move and organize themselves in an arbitrary fashion. 
Each user is free to roam about while communication with others. The path between each pair of the users may have multiple 
links and the radio between them can be heterogeneous. This allows an association of various links to be a part of the same 
network. Mobile ad-hoc networks can turn the dream of getting connected "anywhere and at any time" into reality. 

Ad hoc networks have become increasingly relevant in recent years due to their potential applications in military 
battlefield, emergency disaster relief, vehicular communications etc. In ad hoc applications, collaboration and communication 
among a group of nodes are necessary. Instead of using multiple unicast transmissions, it is advantageous to use multicast in 
order to save network bandwidth and resources. Multicasting is a communication process in which the transmission of 
message is initiated by a single user and the message is received by one or more end users of the network. 

The objective of a multicast routing protocol for mobile ad hoc networks is to support the dissemination of information 
from a sender to all the receivers of a multicast group while trying to use the available bandwidth efficiently in the presence of 
frequent topology changes. Multicasting is especially important in mobile ad hoc networks (MANET) (Osmah, 2009) because 
one to many communication is especially important in the context of ad hoc networks. Over the past few years, several 
multicast routing protocols have been proposed for ad hoc networks. On the basis of comparison of multicasting protocols, 
Protocol for Unified Multicasting through Announcement (PUMA) has been chosen for initial implementation. PUMA does not 
rely on any unicast routing approach. It delivers data at a higher efficiency, while also provides a tight bound for control 
overhead in a wide range of network scenarios. Secure communication is a major concern in PUMA, especially because 
multicasting protocols are applied in areas such as audio/ video conferencing, corporate communications, collaborative and 
groupware applications. The rest of the paper is organized as follows Section II presents an overview of the PUMA protocol. 
Section III] shows Simulation on NS-2 and concluding remarks are made in Section IV. Finally, future work is discussed in 
Section V. 


2. PUMA 


AD HOC NETWORKS 

A wireless ad hoc network is a decentralized type of wireless network. The network is ad hoc because it does not rely on a preexisting infrastructure, 
such as routers in wired networks or access points in managed (infrastructure) wireless networks. Instead, each node participates in routing by 
forwarding data for other nodes, and so the determination of which nodes forward data is made dynamically based on the network connectivity. In 
addition to the classic routing, ad hoc networks can use flooding for forwarding the data. An ad hoc network typically refers to any set of networks 
where all devices have equal status on a network and are free to associate with any other ad hoc network devices in link range. Very often, ad hoc 
network refers to a mode of operation of IEEE 802.11 wireless networks. It also refers to a network device's ability to maintain link status information 
for any number of devices in a 1 link (aka "hop") range, and thus this is most often a Layer 2 activity. Because this is only a Layer 2 activity, ad hoc 
networks alone may not support a routeable IP network environment without additional Layer 2 or Layer 3 capabilities. The earliest wireless ad hoc 
networks were the "packet radio" networks (PRNETs) from the 1970s, sponsored by DARPA after the ALOHAnet project. 
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Table 1 Multicast 


Announcement Packet 


Format 


Group ID 


Core ID 


Sequence Number 


Parent ID 


End-to-end Delay: 


The average time 
taken by a data 
packet to arrive in 
the destination. It 
also includes the 
delay caused by 
route discovery 
process and the 
queue in data 
packet 
transmission. Only 
the data packets 
that successfully 
delivered to 
destinations that 
counted. 

> (arrive time — 
send time ) / > 
Number of 
connections 


Multicast: 

It is the delivery of a 
message or 
information to a 
group of destination 
computers 
simultaneously in a 
single transmission 
from the source. 
Copies are 
automatically 
created in other 
network elements, 
such as routers, but 
only when the 
topology of the 


network requires it. 
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PUMA (Amuthan et al.) is a reactive routing protocol which discovers route only when it is required. The most noticeable 
aspect of PUMA is that it uses a very simple and effective method to establish and maintain the mesh, this results in a low 
control overhead. Its multicast connectivity is established and maintained by means of receiver initialization approach in which 
the receivers joins into the multicast group by using address of core node without the need for network-wide flooding of 
control or data packets from all the sources of the group. Each group has exactly has one special node which is called as 
core node in the group. PUMA uses the shared mesh based multicast topology for constructing routes to the members of the 
multicast group without depending upon any unicast routing protocol. Multicast group maintenance of PUMA is achieved by 
using the soft state approach where in which the multicast group membership and its associated routes are refreshed 
periodically by flooding its Multicast Announcement (MA) packet. 


2.1. Control Packet 


PUMA uses a single control packet called Multicast Announcement 


$1 Nl N2 $2 N3 (MA) to create and maintain its multicast topology in mobile ad hoc 
O O O O O networks. Multicast announcements are used to: 


- elect cores dynamically 
“is NS N6 Distance to core=1 RS - determine the routes for sources outside a multicast 
O O O © — @) group to unicast multicast data packets towards the group 
= afi - join and leave the mesh of a group 


Distance to core =2 


- maintain the mesh of the group. 


NB NO Core N10 Each multicast announcement specifies a sequence number, the 
O O ——_ @ Qs address of the group (group ID), the address of the core (core ID), 
R2 peemenamest the distance to the core, a mesh member flag that is set when the 
ZL i sending node belongs to the mesh, and a parent that states the 
-, pasencanicun~ Nis ane preferred neighbor to reach the core. Table1 depicts the multicast 

YY oO maalit any *” announcement packet format. 
/ M3 Nis Mesh membership code — this field is set to 1 when a node 

& wants to join into the group; else it is unset. 
NIT Ns N19 Distance to core — hop count from the current node to core 
O O © O ~ node. 


Dentin ws cone Distance to core = 2 


Propagation of group info from nodes with longer to 
shorter distance to core 


O Me:h-Member 
C) Non-Member 
® 


Propagation of Data Packet towards Core 
—— using Next-Hop information 


Group ID — address of the group. 

Core ID — address of the core node. 

Sequence number — sequence number of the group. 

Parent ID — address of the neighbor to reach the core. 
Successive multicast announcements have a higher sequence 
number than previous multicast announcements sent by the same 
core. With the information contained in such announcements, 


nodes elect cores, determine the routes for sources outside a 
; multicast group to unicast multicast data packets towards the 
Figure 1 group, notify others about joining or leaving the mesh of a group, 
Mesh Structure in PUMA and maintain the mesh of the group. 


2.2. Connectivity Lists and propagation of Multicast Announcements 

A node which is core of a group transmits multicast announcements periodically for that group. As the multicast 
announcement travels through the network, it establishes a connectivity list at every node in the network. Using connectivity 
lists, nodes will be able to establish a mesh, and route data packets from senders to receivers. A node stores the data from all 
the multicast announcements it receives from its neighbors in the connectivity list. Fresh multicast announcements overwrite 
entries with lower sequence numbers for the same group. For a given group, a node has only one entry in its connectivity list 
from a particular neighbor and it keeps only that information with the latest sequence number for a given core. Each entry in 
the connectivity list, it stores the multicast announcement, stores the time when it was received, and the neighbor from which 
it was received. Next the node generates its own multicast announcement based on the best entry in the connectivity list. For 
the same core ID and sequence number, multicast announcements with smaller distances to the core are considered. When 
all those fields are the same, the multicast announcement that arrived earlier is considered. After selecting the best multicast 
announcement, the node generates the fields of its own multicast announcement i.e. Core ID, Group ID, Sequence number, 
Distance to core, Parent, Mesh member. The connectivity list stores information about all the routes that exist to the core. 
When a core change occurs for a group then the node clears the entries of its old connectivity list and builds a new list, 
specific to the new core. 


2.3. Mesh Establishment and Maintenance 

At the initial stage only receivers are considered as mesh members and their mesh member flag is set to TRUE in the MA's. 
Non receivers consider themselves as mesh members if and only if they have at least one mesh child in their connectivity list 
(Figure 1). A neighbor in the connectivity list is a mesh child if 

(i) Its mesh member flag is set 

(ii) The distance to core of the neighbor is larger than the node’s distance to core 

(iii) The multicast announcement corresponding to this entry was received in within a time period equal to two MA intervals 

If a node has a mesh child and is hence a mesh member, then it means that it lies on a shortest path from a receiver to the 
core. This condition is used to ensure that a neighbor is still in the neighborhood. 


2.4. Core Election Procedure in PUMA 

PUMA chooses a core for each multicast group in the network. Each connected component has only one core. If one receiver 
joins the group before other receivers, then it becomes the core of the group. If several receivers join the group at the same 
time, then the one with highest ID becomes the core of the group. 

When a receiver needs to join a multicast group, it first determines whether it has received a multicast announcement for 
that group. If the node has received, then it takes on the core specified in the announcement it has received, and it transmits 
the multicast announcements that specifies the same core for the group. Otherwise it assumes itself as the core of the group 
and starts transmitting multicast announcement periodically to its neighbors stating itself as the core of the group and a hop 
count of O distances to itself. Nodes propagate multicast announcements based on the best multicast announcement they 
receive from their neighbors. A node that believes itself to the core of a group, it transmits multicast announcements 
periodically for that group. As the multicast announcement pass through the network, it establishes a connectivity list at every 
node in the network. Connectivity list is used to form a mesh structure and to route data packets from receivers to the core. 

A node keeps track of the data from all the multicast announcements it receives from its neighbors in the connectivity list. 
Fresher multicast announcements from a neighbor overwrite entries with lower sequence numbers for the same group. Hence 
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Table 2 Connectivity List at node 6 Core ID = 11 
Group ID = 224.0.0.1. Seq No = 79 


5 1 11 12152 
1 1 11 12180 
A 2 5 12260 


Table 3 Performance Evaluation of PUMA 
Protocol 


50 135.72 209.86 8.0537 
75 138.03 400.70 12.7654 
100 156.71 651.07 15.4042 
125 170.62 713.65 16.9352 


all the nodes in a group store the recent information about a neighbor for each core in the group. 
Each entry in the connectivity list also stores the time when it was received, and the neighbor from 
which it was received. The node then generates its own multicast announcement based on the 
best entry in the connectivity list. 

While electing core, on receiving a multicast announcement with higher core ID, all entries in 
the connectivity list with a lower core ID are erased. Hence all suitable entries in the connectivity 
list at any point of time have the same core ID and sequence number. Among these suitable 
entries, the entries with a shortest distance to core be qualified as best entries, and the neighbors 
corresponding to these entries are called parents. After selecting the best multicast 
announcement, the node generates the fields of its own multicast announcement in the following 
way: 
Core ID: The core ID in the best multicast announcement. 

Group ID: The group ID in the best multicast announcement. 

Sequence number: The sequence number in the best multicast announcement. 

Distance to core: One plus the distance to core in the best multicast announcement. 

Parent: The neighbor from which it received the best multicast announcement. 

Mesh member: A node sets its membership code field based on whether it is a mesh 
member or non-member. 

After generating its own multicast announcement, it will broadcast to its entire neighbor. The 
connectivity list stores information about one or more routes that exist to the core. When a core 
change occurs for a particular group, the node clears the entries of its old connectivity list and 
builds a new one, specific to the new core. Figure 2 illustrates the propagation of multicast 


a announcements and Table 2 shows the building of connectivity lists. 


The solid arrows indicate the neighbor from which a node receives 


7 connectivity list for neighbors 5, 1, and 7. However it chooses the 
- {1 ) entry it receives from 5 as the best entry, because it has the 
ye. pa shortest distance to core and has been received earlier than the 

ae one from node 1. Node 6 uses this entry to generate its own 


Ny its best multicast announcement. Node 6 has three entries in its 
> \—— 


ma eee —k multicast announcement, which specifies Core ID = 11, Group ID = 
<€ Pe = 3 ) 224.0.0.1, Sequence Number = 79, Distance to Core = 2 and 
+ Z ‘ = Parent = 5. When a node wants to send data packets to the group, 
i a it forwards them to the node from which it received its best multicast 

Ne en 4 announcement. 
4 7 ye 4 5 If that link is broken, then it tries its next best and so on. Hence 
Pa Pd each node in the network has one or more routes to the core. The 
Sustsogae es sf ie multicast nnouncement sent by the core has distance to core set to 
packets dropped ~ zero and parent field set to invalid address. Multicast 
during the ip announcements are generated by the core every three seconds. 
simulation. Packet After receiving announcements multicast announcement with a 
lost = Number of Figure 2 fresh sequence number, nodes wait for a short period (e.g. 100 ms) 
packet send — Dissemination of Multicast Announcement to collect multicast announcements from multiple neighbors before 


Number of packet 


generating their own multicast announcement. 


Lica When multiple groups exit, nodes collect all the fresh multicast announcements they receive, and broadcast them 
periodically for every multicast announcement interval. However, multicast announcement representing groups being received 
for the first time, resulting in a new core, or resulting in variations in the mesh membership code are forwarded immediately, 
without aggregation. This is to pass up delays in critical operations, when electing core node and establishing mesh structure. 
3. SIMULATION SCENARIO 
The performance of packet delivery ratio is evaluated by computer simulation using ns 2.31. Network Simulation environment 

a (NS2) (The Network Simulator) is used for setting up the experimental setup for multicasting the data packets. The main goal 
Packet Delivery iz] nam puma.nam is to perform streaming of packets over ad 
gama iiae Ble Yows epntyse == hoc networks. Multicast routing protocol 
numbar of dalnnered | al < . a Sa PUMA is used to achieve scalability in the 
data packets to the a é * network. PUMA achieves desired packet 
destination. This a delivery ratio with variable number of nodes. 
illustrates the level 2 Figure 3 shows the streaming of data packets 

of delivered data to a over IEEE 802.11 using PUMA. Table 3 

the destination. i. shows the results of PUMA protocol 

2 Nomar Gr performance parameters for varying 25 to 

packet receive / > ‘ fi 

Number of packet 125 nodes. Based on the simulation results 

send shown in Table 3 the routing overhead of 

The greater value PUMA is far less compared to other multicast 

of packet delivery k 5 routing protocols. Also for increasing number 

ratio means the barin MPPPTOA IMO EOTAL I MOTOTOTATTPerOTOORPTOTOTOATOrerOOnY nTerOTOTD nererOrnT rPOronOOD PrOTOTOO AePrOTo Mean POTATO MPO TT AT of nodes, the throughput and packet delivery 
better performance ratio of PUMA is higher than many other 

of the protocol. d 

i: routing protocols. 
niguies 4. CONCLUSION 
Streaming of data packets over IEEE 802.11 using PUMA This paper evaluates performance of the 


multicast routing protocol PUMA. The results 


show that PUMA outperforms other multicast protocols in terms of throughput, packet delivery ratio and scalability. PUMA 
incurs far less overhead as compare to tree based multicast protocols and has higher delivery ratios because tree based 
protocols have to maintain tree structure so they expend too many packets which leads to congestion. Secure communication 
is a major concern in multicast ad hoc networks, especially because multicasting protocols are applied in many emerging 


applications. 


FUTURE WORK 


Future work will mainly focus on performance analysis of PUMA to achieve secure streaming of the scalable video streams 


over WiMAX using PUMA. 
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